A three-dimensional representation for program execution

Modern graphical workstations make possible interactive real-time manipulation of three-dimensional objects. While 3D graphics is usually used to model real-world objects, in this paper we explore an abstract three-dimensional pictorial representation of computer programs. Since programs are descriptions of dynamic processes, the focus is on the dynamic behavior of the graphical representation, resulting in an animation of the program’s execution. The goal is to aid the debugging process by helping the programmer visualize the dynamic aspects of a program’s behavior. 3D representations help make use of the enormous innate power of the human visual system. Shu’s book on visual programming [Shu 881 discusses many projects which use pictorial representations for computer programs and their data. Most of the representations that are described in Shu’s book and other sources are two-dimensional, and concentrate mainly on the static appearance of program code. The experiments described in this paper are aimed at extending the visual vocabulary for graphical programming, using an abstract three-dimensional representation for computer programs in the context of an interactive dynamic debugger. Three-dimensional representations are now made practical by hardware which automatically performs rendering of solid objects just as easily as displaying a line of text. Other graphical techniques employed in this debugger to provide an integrated view of program execution are: a re-roofing process which keeps a fixed viewpoint while displaying a changing context, graphical objects, a reversible control structure, use of 3D rotation to simultaneously present sequential and time-slice views. . Programming in three dimensions the Of as substitution Of Program elements are represented by colored polyhedra. Each program element is labeled by three-dimensional text attached to a face of the program element. The size, shape, color and position of program elements are significant. The properties of tGe polyhedra changgto reflect the current state of the program. Boxes grow, shrink, TH0277-4/89/0000/0111$1 .OOO 1989 IEEE 1 1 1 turn, move, and change color as the program runs. We present this illustration now to show the reader what the display looks like. Later, we explain the reasons for each design choice in detail. The examples in this paper were generated on an Hp 350 Bobcat workstation with a Renaissance display, which has hardware for rendering shaded polyhedra. We are converting to a next generation machine which we hope will be fast enough to manipulate these displays interactively in real time. The examples were produced using a 3D storyboarding system designed by Bob Sabiston, and are currently being hooked to the debugging interpreter described in [Lieberman 871 and [Lieberman 891. Display of programs as tree structures There are two related aspects to the visual representation: static display of program structure, and its dynamic behavior during evaluation. Rather than simply display the static structure of the program as source code text, a more useful graphic representation makes apparent the tree structure of function calls and arguments which comprise the program. In functional languages such as Lisp, the textual syntax uses nested parentheses and "pretty-printing'' to make this tree structure apparent. We have previously experimented with graphical representations that draw the calling tree with functions and arguments represented as nodes and arcs [Lieberman 891. This is a good representation for displaying the tree structure in two dimensions. Note that drawing the function-calling tree is not the same kind of graphical representation for programs as the venerable and justly-maligned flowchart. Another possibility for depicting the function-argument relationship spatially is to use containment of graphic forms. This has been done in several graphical programming projects, with [Smith 791, [Lakin 801, and [Abelson, et. al. 871 as good examples. A large icon representing a function graphically encloses smaller icons which represent arguments. This is the approach adopted here, except in three dimensions rather than two, as illustrated above. This represents a function call to a function named Alpha-Beta, with an argument named Cutoff . We could have more complex three-dimensional abstract pictorial representations of program elements, but here we stick to boxes as the simplest 3D shapes, distinguished only by text labels. Move the focus or move the context? All visual representations for dynamic display of programs are faced with a common design decision: How should we display the relationship between the particular part of the program that is the "focus" of current interest [such as the source expression currently being evaluated] and the rest of the program? There are two fundamental possibilities for display of the viewpoint or current focus of interest. First, the program display itself can remain static, and the viewpoint can move by means of highlighting, blinking, cursor motion or some other attention-getting device. This is the alternative used in most traditional static, textual program representations. Display of source text, highlighting the current expression, and "follow the bouncing ball" cursors are examples of this approach. The alternative, which is much less common in programming environments, is to leave the viewpoint fixed, and alter the display of the surrounding context to reflect the current point of view. Many text editors use both "move the focus" and